1. Field of Invention
The invention related to the system and method of initiating a barcode scan from a landing page.
2. Background of the Invention
The present invention is a useful and novel method for adding new barcode scanning capabilities to mobile landing pages. Mobile barcode scanners have previously been constrained to software applications associated and stored on the mobile device. Landing pages were unable to simulate the results of mobile barcodes scanners because they didn't have access to the hardware required.
Landing Pages
Mobile landing pages, or landing pages, are a collection of images, files, data, text, links, movies, applications or clips located in a single address on the internet. Mobile landing pages are designed to detect the type of device, including make and model, and then setting the screen width to match the physical size of the device's screen. Mobile landing pages provide a variety of unique challenges for the developer including brevity of the copy on a single page; legible text and images without zooming; using only mobile-friendly plug-ins; call-friendly phone number using click-to-call; map linked to address; links are large enough to be thumb-friendly with zooming; favoring local content using geographic identification technologies; and keeping fillable forms brief.
Applications tied to the webpage began to grow in popularity after Google's successful implementation of HTML5-based apps. The competitive advantage for web-based application was the ability to expand audience reach and quickly issue version updates.
Native Mobile Applications
A native mobile application (or “app”) is software written for mobile devices that performs a specific task, such as a barcode scanner, game, calculator, music player, etc, The application is specifically designed to run on a device's operating system and machine firmware therefore an app must be adapted for different devices. Apps exploded in popularity in 2008 when Apple introduced the “App Store.” Apple solved many app development impediments by providing a standardized software development kit (SDK) to third-party developers and then providing a built-in billing feature through Apple iTunes.
Although not supported quantitatively, native mobile applications are largely viewed as the more successful platform compared with web-based applications. There are approximately five hundred thousand (500,000) native mobile applications currently offered today. However, there are relatively poor statistics on the number of web apps for making a direct comparison.
As smartphone technology evolves two different camps of development have formed. One vision sees the development of web-based applications as the future of mobile application development. Web applications can be developed without the restrictions inherent in native mobile application approval. Web applications also are platform independent so developers don't have the burden of writing the application in all the available operating systems. As of this writing, there are a dozen different mobile operating systems. So writing to web-based applications is cheaper, faster and easier than native applications. However, web applications have a perception problem with consumers. They view the web as place for a quick one-time data feed. For repeated needs, consumers turn to native applications.
Other developers believe the early trend of natively installed applications will maintain its dominance in how technology is delivered. Much of this opinion has to do with the significant resources already committed to the approach by developers. Updating a dozen platforms is seen as a given instead of an obstacle. Additionally, current native programming allows for more sophisticated look, feel and functionality than web-based applications.
The New York Times pontificated on the conflict between the two development styles and declared, “THE Web is poised for a comeback.” That may be an exaggeration of the rife between the camps, but we believe new Hyper Text Markup Language (HTML) will blur the distinction to the consumer. Since they are both presented on the same mobile screen, consumers will find it more and more difficult to differentiate between a native application and a web-based application. This will lead marketers to ask if the current nature of web applications is more important than technology flashiness.
The ability to combine the mobile phone's hardware into landing page capabilities has been previously limited by operating system functionality, carrier limitations, and artificial technical restrictions adopted by application distributors. We anticipate we will see these restrictions soften and then finally fall away. This will provide new capabilities to streamline the interface between executables on a webpage and the required application+hardware resources on the device.
Resource Sharing Between Landing Pages and Mobile Application
There are limited examples of resource sharing by a mobile landing page and native applications on the mobile device. The two most common examples are related to mapping capabilities and the out-call function of the telephone. For instance, a user would perform an internet search for “ABC Plumbing” which returns a listing of various plumbing companies using the name. The search page may display a telephone number that can be dialed by clicking on the number and the user confirming they wish to call. The user may also find a similar phone on the landing page of the “ABC Plumbing's” website. Like the search engine, the user only needs to click the phone number and confirm the desire to complete the call. When the call is ended, the user remains in the phone application until they give the commands to toggle away.
Similarly, a user can click on an address or map in the internet search page and be routed to one of three options:                1. An on-line mapping tool,        2. An embedded map in the landing page,        3. A native application stored on the mobile device.        
In the third option, the address is transferred to the local mapping application and the application is automatically launched. Like in the telephone example, the user remains in the mapping application until they toggle away.
The addressable problem with these current implementation examples is the mobile landing page loses focus which is undesirable for marketers and developers. Marketers want to maintain the longest possible engagement with the end user. Not only is “time spent” on a mobile landing page a common measure of design success, the mobile forum is a rare opportunity to engage a consumer without distracting outside advertising messages. So marketers are hesitant to send the consumer to an outside resource they don't control directly.
Programming the Data Pass Between the Web Page and the Native Application
Passing data between mobile landing pages and native applications is inherently difficult and can lead to a skewing of the associated reporting data. For instance, if a user were to click a link in a native social media application, the application does not transmit the referral information to the web page. The webpage would read the referral as a direct hit to the website and dramatically skew critical metrics.
When passing data from the mobile landing page to the application, there are several methods available to the programmer. For instance, a session key is a single-use alphanumeric string for encrypting communication within the same session. The purpose of the session key is two-fold. First, a session key is used to secure the communications between two computers or processors. Second, the session key is transmitted with each subsequent communication to provide a cohesive string of communication.
An application programming interface (API) is a system of rules and regulations for passing data between two unrelated software programs. These APIs are a combination of the proprietary information encoded in a standardized format.
A characteristic of all the programming techniques for passing data is they comprise an alphanumeric string, referred to as a session string in the present invention.
However, what is missing in the data pass is the ability to swap information from the webpage to the native application and back to the webpage. Take the example of a car dealership with a mobile landing page showing inventory on a particular lot. A consumer shopping the lot notices a car they wish to investigate for more information. For this process to work in a desirable manner:                1. The consumer would press a scan button on the mobile landing page;        2. The mobile landing page would call a mobile barcode scanner installed on the user device;        3. Using the scanner application installed on the user device, the consumer would scan the vehicle identification number (VIN) number of the automobile;        4. The scanner would pass the information to the originating mobile landing page;        5. The originating mobile landing page would then search the car dealer's inventory for the item and display the associated data on the dealer's mobile landing page.        
However, steps 4 and 5 would not happen in the prior art. Instead, the scanner may parse the information, determine the brand and model of the VIN and route the consumer to a website that may be competitive with the owner of the originating mobile landing page. It may route the consumer automatically to a website preferred by the developer—such as insurance or vehicle history websites. If the consumer was routed to the originating dealership through a web search, it would likely happen by coincidence only. This then makes it undesirable for the dealership to use mobile barcode scanning technology on the mobile landing page. Instead the developers would have to explore less precise ways, and less desirable ways, for the consumer to find information on a vehicle on their lot.
All the previous designs for combining the resources of a mobile landing page with mobile device resources heretofore known suffer from a number of disadvantages:                1. The mobile landing page is unable to call hardware, such as a camera, on the native device.        2. The available hardware resources vary across mobile devices. One device might employ an auto focus camera and another device might have a single focus camera with automatic flash.        3. The programming code to call an application varies from mobile platform to mobile platform which requires additional programming considerations.        4. The applications a programmer can call from a mobile landing page vary from one platform to the next.        5. Multiple native applications perform the same function. If a mobile landing page wants to use a native tool for calculating a mortgage payment, the program could call a simple calculator or specialized mortgage calculator.        6. The native application can't return information to the mobile landing page. If the consumer determines a mortgage amount using a native calculator, the information would be contained to the native application. If the web-based application wished to store the information for later comparison by property, it would not be able to use the native application.        
When the mobile landing page links to a native application, it is unable to force a return focus to the originating mobile landing page after the application's task is completed. So the mortgage consumer would be left in the calculator application until the user toggles back to the browser. This is a paramount concern of brand and website developers when considering if the landing page should use an outside application on the local mobile device.